The following definitions are herewith defined:
3GPPThird Generation Partnership ProjectAAAAuthentication, Authorization and AccountingGAAGeneric Authentication ArchitectureGBAGeneric Bootstrapping ArchitectureBSFBootstrapping Server FunctionAKAAuthentication and Key AgreementIMIP MultimediaISIMIM Services Identity ModuleNAINetwork Access IdentifierMNMobile NodeUEUser EquipmentEV-DOEvolution Data Only3GPP GBA (see 3GPP TS 33.220 “GAA:GBA”, attached as Exhibit A to the above-referenced U.S. Provisional Patent Application No. 60/759,487) aims at specifying a mechanism to bootstrap authentication and key agreement for application security from the 3GPP AKA mechanism. GBA is also being introduced in 3GPP2, where apart from AKA, bootstrapping based on legacy key materials, including the SMEKEY (for CDMA1x systems) and MN-AAA Key (for CDMA1x EV-DO systems), are also being standardized. As a result, when operating in a 3GPP2 system a MN may support, or may be required to support, more than one authentication and bootstrapping mechanism. A technique is therefore needed for the MN and the network to agree on the algorithm set to be used in the bootstrapping. The same is required for future terminals that support both 3GPP and 3GPP2 networks, such that a 3GPP terminal may roam in a 3GPP2 network (and vice versa) and still use GBA. In addition, it is possible for operators to deploy both 3GPP and 3GPP2 networks in the same geographical location. In such cases, terminals also have to negotiate with the network the bootstrapping mechanism to use.
3GPP supports only one authentication and bootstrapping mechanism, i.e., the Digest-AKA mechanism and AKA protocol with 3GPP-defined algorithms. Usage of AKA with Digest authentication is specified in Digest-AKA (see IETF RFC 3310 “Digest AKA”, attached as Exhibit B to the above-referenced U.S. Provisional Patent Application No. 60/759,487).
In 3GPP2 there are different mechanisms for bootstrapping supported in the network side, as both legacy and non-legacy terminals need to be supported.
The MN may have support for multiple authentication and key generation mechanisms (e.g. AKA, MN-AAA, CAVE) and may have multiple pre-provisioned secrets. In 3GPP2 there is a mechanism selection procedure defined, which mandates that the MN inserts into the payload of the first message it sends to the BSF the list of supported authentication mechanisms, enabling the BSF to select the authentication mechanism that it prefers. Once the BSF selects the authentication and key generation mechanism, it contacts the correct database and fetches authentication data. For instance, if the MN supports MN-AAA, in addition to other mechanisms, and the BSF selects MN-AAA, then the BSF will contact the H-AAA to fetch a challenge.
The MN has also one or more identities. For example, if the MN has an ISIM application, then it has a private identity. If the MN is an EV-DO terminal, then it has an NAI. If the MN is a 1x terminal, then it has an IMSI-like identity.
This creates a problem, in that when the MN first contacts the BSF by sending an HTTP GET request (according to 3GPP2 S.P0109-0, Version 0.6, 8 Dec. 2005, “Generic Bootstrapping Architecture (GBA) Framework”, attached as Exhibit C to the above-referenced U.S. Provisional Patent Application No. 60/759,487), it is mandated to insert its identity into the request. Because most of the identities can only be used with specific authentication and key generation mechanisms (e.g., private identity can only be used with AKA, IMSI can only be used by CAVE, EV-DO NAI can only be used by MN-AAA), by selecting and including one of its identities into the GET request the MN pre-selects implicitly the authentication mechanism as well. With one specific identity already inserted, the BSF cannot make another choice for the mechanism than the one which that identity can be used with. Alternatively, a mapping of the different identities of a MN may need to be accessible by the BSF, but this approach may not be desirable for a number of reasons.